Web services (generally XML-based) are a powerful vehicle for reusing shared application logic across diverse business processes as shown schematically in FIG. 10. These processes often need to traverse multiple departments, business units, and partners; each residing in separate security domains with independent preferences, capabilities, and requirements. As a consequence, serious communication, propagation, and processing problems arise as each independent security domain attempts to share Web services and applications. This problem—known as a “federation” problem—complicates and restricts the widespread implementation of Web services.
The fundamental challenge in the federation problem is a two-fold communication issue: First, how does an application in one security domain determine access rights for the identities coming from another security domain, and second, how does that same application determine those access rights without first knowing which identities are entitled to access the originating application? This flexible concept of identity, wherein users originating from one enterprise can authenticate at a second enterprise is known as “identity federation”.
Several new technologies and standards have been proposed to address the identity federation problem for the Web. However, the problem for Web services has been unresolved. In order to reach their potential in the modern extended enterprise, Web services must be able to effectively bridge application identities across diverse security domains.
One barrier to a solution to the identity federation problem is the proliferation of Identity Silos (an Identity Silo is a locally created and accessed identity store containing usernames and passwords that which typically cannot be re-used by another application for authentication and authorisation and provide no means to synchronize with another identity store) creates significant hurdles to the successful integration of applications residing in different security domains. This is equally true if the integration is based on Web services technology.
For consistent management, identities are typically stored in the same security domain as the application. An identity may represent another application, a human user, or a group of users and consist of elements such as common name, fully qualified name, group, role, certificate, and security clearance. During the authentication and authorization process, the exact elements in an identity are matched to the functional requirements of the applications or Web services served by the identity provider.
If a legitimate user, application, or Web service authenticates against a corresponding identity provider in one identity silo, their identity or any evidence of the authentication may have no relevance when requesting access to another application or Web service in another identity silo inside or outside the enterprise. In this case, the integration is broken and the authorization in one silo will fail even though the authentication succeeded in another silo. For Web services, this problem is compounded because most interactions happen between applications and no practical user intervention is possible.
Attempts to integrate disparate identity systems have traditionally used one or more of the technical approaches. These traditional approaches include: custom hard coding of rules and translators that map, transform, or otherwise manipulate identities exchanged between two silos; identity consolidation which maps identities associated with one authentication source to a single consolidated identity for authorization purposes; and directory synchronization which addresses some of the shortcomings of consolidation by replicating some or all of any remote identities into a separate store. While each approach provides part of the solution, each also has fundamental shortcomings that result in unwanted and risky side effects and are generally only effective in within a single administrative zone with a small number of identity stores.
Another common approach is the Single Sign-On (SSO) that provides single login access to a variety of back-end systems through Web portals and other gateway applications. A given entity signs on once and is granted the correct access and entitlements on multiple systems through some form of opaque cookie or token. Scaling SSO systems to encompass a broader spectrum of integration scenarios, however, can be challenging.
The SSO model does not eliminate the proliferation of disparate user IDs and passwords; it simply masks this issue for some pre-defined processes. Local applications are still responsible for authorizing users and determining what to do with the authentication token. This requires pre-negotiation of roles and entitlements and considerable amounts of custom code to process or map the incoming identities.
In the Web environment, most SSO products use cookies as evidence of authentication. This works well for human users signing into a Web browser page, but does not translate well between applications or in Web services integrations where there is no equivalent to a browser application. In both of these situations, the deployment of custom code or platform-specific agents is required to properly interpret and verify the cookies.
To address this problem, several SSO products now incorporate standards based tokens that offer more flexibility than proprietary cookies. An example is SAML (Security Assertion Markup Language), which defines an XML framework for exchanging authentication and authorization information between enterprises or web sites. The SAML specification itself does not define any new authentication technologies or approaches or address privacy or security policies. SAML forms the basis for many Web-based SSO systems and has proven interoperability between major vendors. Other standards activities such as WS-Federation standard are focused on strategically extending applications and Web services beyond a security domain firewall for Web services-based integrations.
Typically, the originating identity and some form of evidence of that identity's successful authentication are contained in a SAML assertion. Systems can pass these SAML tokens both within and across the firewall to a corresponding SAML “receiver” to receive, process, and verify the token. This approach—sometimes referred to as “Federated SSO” or “Federated Identity”—requires that exact security protocol for the token. If not protected in some manner, the same token can be used for subsequent replay attacks.
SSO systems still require considerable pre-negotiation of identity context between silos as well as the code to support proper authorization within this context. The introduction of SAML does provide a potentially powerful mechanism for exchanging both identity and evidence of authentication, but still requires significant infrastructure to securely exchange tokens, validate their authenticity, and correctly authorize users. This can lead to an expensive and time-consuming Web services implementation process even if an SSO system is already in place for an existing Web portal application.
The majority of today's identity-related integration issues are due to integrations of a moderate number of applications or users to address the specific business needs of an organization. The goal of these integrations is to bridge identity silos, not to deploy a complex infrastructure designed to federate identity to thousands of possible applications.
Identities and related management policies are constantly in flux due to both ordinary and extraordinary changes in operational, business, and regulatory needs. Any solution must be able to adapt to these changes in near real time without driving uncontrollable delays or costs. The solution must also leverage any investment in existing infrastructure, regardless of vendor or platform.
Identity and integration-related standards are evolving rapidly in various standards bodies. A solution must take advantage of existing work as well as be able to adapt to new standards as they become ubiquitous. This ensures maximum flexibility when interoperating with other systems and the use of proven, industry-accepted approaches to specific problem sets.
A solution adds little value if it requires the development of new code or a significant integration effort to become operational. To ensure consistency, reliability, and rapid deployment without unnecessary dependencies on third-party systems, all required attributes and technologies should be present in a tightly integrated, turnkey solution.
To allow local administrators to manage the policies relevant to their respective security domains, the solution must permit independent control over authentication and authorization processes. Authentication should occur close to the requester to ensure maximal reliability in the identity assertion, and authorization of the requester should occur close to the provider to maintain strict localized access control.
Identity information often provides access to sensitive data and must be protected during an exchange. Security tokens should be shielded from expropriation and not reused through placement in a new message or replay in the same message. To provide a thorough, two-sided audit trail, the requestor's authentication provider and the authorizing provider should securely log all actions performed by a requestor.
Accordingly, there still remains a need for a system that enables integration across identity silos.